Distributed computing systems, such as client-server systems, rely on communication between different computer programs. The format of messages sent from program to program varies greatly from one system to the next. Messages in a particular system may be of a compound format, including both data and metadata. The data are the values of information items potentially important to the transaction. The metadata are values describing the data itself in a way to extend the recognition and usefulness of the data for processing by computer means. Examples of metadata include the name, representation format, and size of an information item.
Systems utilizing compound messages are on the rise with the growing popularity of XML. A message (document) in XML representation contains data values and metadata intermixed. The metadata exists in the form of tags. Other compound message types exist, such as the EDI transaction set or the SGML document. What is common among these compound message representations is the presence of data and metadata within the message.
The use of the compound message eliminates the need for the receiving computer service program module to have been developed to include a full and precise definition of the message contents. A program module receiving a compound message processes the metadata to recognize and extract the desired information items at runtime. While the receiving program module is more resilient to changes in message content, it imposes the increased processing burden of parsing the inbound message to first extract metadata and then, in turn, to extract the actual information items. This additional processing burden becomes overwhelming particularly in modern data processing systems that exploit modular designs.
Modern data processing systems exploit modularity to provide flexibility for change. For example, a loan request submitted to a bank may require compliance with many different regulatory schemes. Moreover, the precise set of schemes may vary from request to request depending on, for example, the region in which the requestor is located. In constructing a data processing system to process loan requests, the bank will implement a different service module for each of the regulatory schemes potentially involved. A loan request is routed for processing to each of the service modules relevant to that particular request. If a regulatory scheme changes, only the respective service module needs to be modified. If a new regulatory scheme emerges, a new service module is added.
The modularity greatly enhances the maintainability and responsiveness to change of the data processing system, but magnifies the processing burden when compound messages are used to dispatch the loan request to the service modules. Each service module may use only a fraction of the information items in the loan request document, but each service module potentially parses all of the message to get the subset of information items it needs. The cost in terms of CPU and memory resources is substantial.
The above-described modularity of a modern data processing systems is often implemented using Object Oriented Programming (OOP). Accordingly, the service module is preferably invoked by calling a method of a programming object's exposed interface.